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Traffic Engineering Extensions to OSPF Version 3 


Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The IETF Trust (2008). 

Abstract 
This document describes extensions to OSPFv3 to support intra-area 
Traffic Engineering (TE). This document extends OSPFv2 TE to handle 


IPv6 networks. A new TLV and several new sub-TLVs are defined to 
support IPv6 networks. 
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Introduction 


OSPFv3 has a very flexible mechanism for adding new LS types. 
Unknown LS types are flooded properly based on the flooding scope 
bits in the LS type [OSPFV3]. This document defines the Intra-Area- 
TE-LSA to OSPFv3. 


For Traffic Engineering, this document uses "Traffic Engineering 
Extensions to OSPF" [TE] as a base for TLV definitions. New TLVs and 
sub-TLVs are added to [TE] to extend TE capabilities to IPv6 
networks. Some existing TLVs and sub-TLVs require clarification for 
OSPFv3 applicability. 


GMPLS [GMPLS] and the Diff-Serv MPLS extensions [TE-DIFF] are based 
on [TE]. These functions can also be extended to OSPFv3 by utilizing 
the TLVs and sub-TLVs described in this document. 


Requirements Notation 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 
[REC-KEYWORDS] . 
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2. Intra-Area-TE-LSA 


A new LS type is defined for the Intra-Area-TE-LSA. This is 
different from OSPFv2 Traffic Engineering [TE] where opaque LSAs are 
used to advertise TE information [OPAQUE]. The LSA function code is 
10, the U-bit is set, and the scope is set to 01 for area-scoping. 
When the U-bit is set to 1, an OSPFv3 router must flood the LSA at 
its defined flooding scope even if it does not recognize the LS type 
[OSPFV3]. 


0 1 2 3 
Oecd 22 3456.7 8 90 T2384 56 8 90: 1.:2 3:45 6.71,8-90.1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| LS age |ıļolļ1] 10 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Link State ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Advertising Router 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| LS sequence number 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| LS checksum | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 
hs TLVs sE 


OSPFv3 Intra-Area-TE-LSA 


The Link State ID of an Intra-Area-TE-LSA is an arbitrary value used 
to maintain multiple Traffic Engineering LSAs. The Link State ID has 
no topological significance. 


The format of the TLVs within the body of an Intra-Area-TE-LSA is the 
same as the format used by the Traffic Engineering extensions to OSPF 
[TE]. The LSA payload consists of one or more nested 
Type/Length/Value (TLV) triplets. The format of each TLV is: 


0 1 2 3 
Orde 2B 436 7 8 9,001 2 3:45. 67.890. D2 8 Ae 6 oF Be O08 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Value... | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


TLV Format 
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2s 


3% 


The Length field defines the length of the value portion in octets 
(thus, a TLV with no value portion would have a length of 0). The 
TLV is padded to 4-octet alignment; padding is not included in the 
Length field (so a 3-octet value would have a length of 3, but the 
total size of the TLV would be 8 octets). Nested TLVs are also 32- 
bit aligned. For example, a 1-byte value would have the Length field 
set to 1, and 3 octets of padding would be added to the end of the 
value portion of the TLV. Unrecognized types are ignored. 


1. Intra-Area-TE-LSA Payload 


An Intra-Area-TE-LSA contains one top-level TLV. There are two 
applicable top-level TLVs: 


2 - Link TLV 
3 - Router IPv6 Address TLV 
Router IPv6 Address TLV 


The Router IPv6 Address TLV advertises a reachable IPv6 address. 
This is a stable IPv6 address that SHOULD be reachable if there is 
connectivity to the OSPFv3 router. 


The Router IPv6 Address TLV has type 3, length 16, and a value 
containing a 16-octet local IPv6 address. A link-local address MUST 
NOT be specified for this TLV. It MUST appear in exactly one Traffic 
Engineering LSA originated by an OSPFv3 router supporting the TE 
extensions. The Router IPv6 Address TLV is a top-level TLV as 
defined in "Traffic Engineering Extensions to OSPF" [TE], and only 
one top-level TLV may be contained in an LSA. 
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0 1 2 3 
DL a NAS A IO A a BG IO 
PR A A A + + e + + d+ + + d+ + ++ +++ +++ +++ +++ 
| 3 | 16 | 
tata tata tar O + tata tata tata tata + + d+ + ++ +++ +++ +++ +++ 


+-+-+-4+- —+-+-+-+ 
+-4+-+-4+- Router IPv6 Address —+-+-+-+ 
+-+-+-4+- —+-+-4+-+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type A 16-bit field set to 3. 
Length A 16-bit field that indicates the length of the value 
portion in octets. For this TLV, it is always 16. 


Value A stable and routable IPv6 address. 
Router IPv6 Address TLV 


4. Link TLV 


The Link TLV describes a single link and consists of a set of sub- 
TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID sub- 
TLV are applicable to OSPFv3. The Link ID sub-TLV can’t be used in 
OSPFv3 since it is defined to use the OSPFv2 identification for the 
Designated Router (DR) on multi-access networks. In OSPFv2, 
neighbors on point-to-point networks and virtual links are identified 
by their Router IDs while neighbors on broadcast, Non-Broadcast 
Multi-Access (NBMA), and Point-to-Multipoint links are identified by 
their IPv4 interface addresses (refer to section 8.2 in [OSPFV2]). 
The IPv4 interface address is not known to OSPFv3. In contrast to 
OSPFv2, OSPFv3 always identifies neighboring routers by their Router 
IDs (refer to section 2.11 in [OSPFV3]). 


Three new sub-TLVs for the Link TLV are defined: 
18 - Neighbor ID (8 octets) 


19 - Local Interface IPv6 Address (16N octets, where N is the 
number of IPv6 addresses) 


20 — Remote Interface IPv6 Address (16N octets, where N is the 
number of IPv6 addresses) 
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The Neighbor ID sub-TLV is mandatory for OSPFv3 Traffic Engineering 
support. It MUST appear exactly once in a Link TLV. All other sub- 
TLVs defined in this document SHOULD NOT occur more than once ina 
Link TLV. If a sub-TLV is specified more than once, instances 
subsequent to the first are ignored. 


4.1. Link ID Sub-TLV 


The Link ID sub-TLV is used in OSPFv2 to identify the other end of 
the link. In OSPFv3, the Neighbor ID sub-TLV MUST be used for link 
identification. In OSPFv3, the Link ID sub-TLV SHOULD NOT be sent 
and MUST be ignored upon receipt. 


4.2. Neighbor ID Sub-TLV 


In OSPFv2, the Link ID is used to identify the other end of a link. 
In OSPFv3, the combination of Neighbor Interface ID and Neighbor 
Router ID is used for neighbor link identification. Both are 
advertised in the Neighbor ID sub-TLV. 


Neighbor Interface ID and Neighbor Router ID values are the same as 
described in RFC 5340 [OSPFV3], A.4.3 Router-LSAs. 


0 1 2 3 
01.234 5:06:-1.8, 1900 1:23 45.6 78. 9:50: 1:23:45 6 1.890: 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 18 | 8 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Neighbor Interface ID | 
+-+-4-4+-4-4+-4-4+-4-4+-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4 

| Neighbor Router ID 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type A 16-bit field set to 18. 

Length A 16-bit field that indicates the length of the value 
portion in octets. For this sub-TLV, it is always 8. 

Value The neighbor’s Interface ID and Router ID. 


Neighbor ID Sub-TLV 
4.3. Local Interface IPv6 Address Sub-TLV 
The Local Interface IPv6 Address sub-TLV specifies the IPv6 
address (es) of the interface corresponding to this link. If there 


are multiple local addresses assigned to the link, then they MAY all 
be listed in this sub-TLV. Link-local addresses MUST NOT be included 


in this sub-TLV. 
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1 2 3 
405 67-8: 9 0 2-2 3-49.69 7-8 900 12° 3. 4.6. 7 8.90 1 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
19 | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-+-+-+-+ 
-+-+-+-+ 
-+-+-+-+ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
o | 
o | 

o) 


Local Interface IPv6 Address 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+-+-+-+ 


-+-+-+-+ 


-+-+-+-+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Local Interface IPv6 Address 


A 16-bit field set to 19. 

A 16-bit field that indicates the length of the value 
portion in octets. For this sub-TLV, it MUST always be a 
multiple of 16 octets dependent on the number of IPv6 
global addresses advertised. 

A list of one or more local IPv6 interface addresses each 
consuming 16 octets. 


Local Interface IPv6 Address Sub-TLV 
nterface IPv6 Address Sub-TLV 


Interface IPv6 Address sub-TLV advertises the IPv6 
associated with the neighbor's interface. This sub-TLV 
al Interface IPv6 Address sub-TLV are used to discern 
allel links between OSPFv3 routers. If the link type is 
the Remote Interface IPv6 Address MAY be set to 


Ishiguro, 


multi-access, 
Alternately, an implementation MAY choose not to send this sub-TLV. 
Link-local addresses MUST NOT be advertised in this sub-TLV. 
Neighbor addresses advertised in link-LSAs with a prefix length of 
128 and the LA-bit set MAY be advertised. 
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0 1 2 3 
O12 2°34 5 6.7 8:9 0 1:23 4. .3.:6 7 8-90 1:2 3.4567. 8.90 1 
Hott t— tit tit e ho tito titi ++ 

| 20 | Length 
Hott ttt ttt titi tat ho ooo ++ 


Ho +++ —+-+-4+-+ 
+-4+-+-4+- Remote Interface IPv6 Address —+-+-+-+ 
+-+-+-4+- —+-+-+-+ 


| | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| o | 

| o | 
o 


EA A A A A A A A A A A A A A A A A A A dd dd q o + +4 


+-+-+-4+- —+-+-+-+ 
+-4+-+-4+- Remote Interface IPv6 Address —+-+-+-+ 
+-+-+-4+- —+-+-4+-+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type A 16-bit field set to 20. 

Length A 16-bit field that indicates the length of the value 
portion in octets. For this sub-TLV, it MUST be a 
multiple of 16 octets dependent on the number of IPv6 
global addresses advertised. 

Value A variable-length Remote Interface IPv6 Address list. 


Remote Interface IPv6 Address Sub-TLV 

5. Security Considerations 
The function described in this document does not create any new 
security issues for the OSPFv3 protocol. Security considerations for 
the base OSPFv3 protocol [OSPFV3] and OSPFv2 Traffic Engineering [TE] 
are applicable to OSPFv3 Traffic Engineering. 

6. Management Considerations 
The typical management interface for routers running the new 


extensions to OSPF for intra-area Traffic Engineering is Simple 
Network Management Protocol (SNMP) based. The extra management 


Ishiguro, et al. Standards Track [Page 8] 


RFC 5329 OSPFv3-Traffic Engineering September 2008 


objects for configuration operations and statistics are defined in 
[OSPFV3-MIB], and an implementation of the extensions defined in this 
document SHOULD provide for the appropriate hooks or instrumentation 
that allow for the MIB objects to be implemented. 


The following MIB variables have been added to the OSPFv3 MIB in 
support of TE: 


ospfv3AreaTEEnabled 
This TruthValue MIB variable in the ospfv3AreaEntry table entry 
indicates whether or not OSPFv3 TE advertisement for OSPFv3 
interfaces is enabled for the corresponding area. The default 
value is FALSE. 


ospfv3IfTEDisabled 
This TruthValue MIB variable in the ospfv3IfEntry table entry 
indicates whether or not OSPFv3 TE advertisement for OSPFv3 for 
the corresponding interface is disabled. This MIB variable is 
only applicable if ospfv3AreaTEEnabled is TRUE for the interface’s 
area. The default value is FALSE. 


7. IANA Considerations 


The following IANA assignments have been made from existing 
registries: 


1. The OSPFv3 LSA type function code 10 has been assigned to the 
OSPFv3 Intra-Area-TE-LSA. 


2. The Router IPv6 Address TLV type 3 has been assigned from the 
existing registry for OSPF TE TLVs. 


3. The Neighbor ID (18), Local Interface IPv6 Address (19), and 
Remote Interface IPv6 Address (20) sub-TLVs have been assigned 
from the existing registry for OSPF TE sub-TLVs. 


8. References 
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[TE] 


8.2. Informative 


[GMPLS ] 


[OPAQUE ] 


[OSPFV3-MIB] 


[TE-DIFF] 
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